1. Field of the Invention
Embodiments of the present invention generally relate to disaster recovery systems and, more particularly, to a method and apparatus for automating device recovery using device configuration information.
2. Description of the Related Art
In a typical computing environment (e.g., a datacenter), administrators and/or users desire highly available applications and quick recovery of host computers after a disaster (e.g., power failure, hurricane and/or the like). Current disaster recovery systems (e.g., SYMANTEC NetBackUp Bare Metal Recovery (NBU-BMR)) store a backup of the host computer (e.g., a physical machine or a virtual machine). When a hardware failure or software fault occurs that disables the host computer, these current disaster recovery systems provision a bare metal server to restore operations at the host computer. Generally, the bare metal server is a computer that does not contain an operating system or any software applications. The bare-metal server may be a computer in which a virtual machine is installed directly on computer hardware rather than within the host operating system (OS).
One or more software programs (e.g., operating systems, applications and/or the like) are installed. One or more associated hardware devices (e.g., an array, a switch, a router, a firewall and/or the like) are also configured (e.g., an Internet Protocol (IP) Address for a Network Interface Card (NIC), a zone for a switch, a Logical Unit Number (LUN) of an array and/or the like). For example, the switch may be configured to assign the bare metal server to a zone that was previously assigned to the host computer. As another example, an array may be configured to provide the bare metal computer with access to one or more LUNs that were previously utilized by the host computer.
Even though the current disaster recovery systems are able to restore entire host computers, these systems are unable to recover an individual hardware device or an application that are associated with the host computer. Nonetheless, various hardware devices and/or applications must be configured to achieve optimal performance and seamless disaster recovery. For example, an array may have a specific LUN configuration, a switch may have a zoning configuration, a firewall may have a packet filtering policy and so on.
Pre-defined templates (e.g., a gold standard set by a hardware vendor) are employed to configure a particular hardware device. Such templates, however, are not customized for each and every type of computing environment (e.g., a data center). Furthermore, the configurations may change over time to accommodate changing computing resources and user needs. Although some hardware devices may have a same function, the templates used for configuration vary from vendor to vendor.
Two or more hardware devices of a same type (e.g., a switch, an array and/or the like) may perform similar functions but be provided by different vendors (i.e., manufacturers). In some instances, the two or more hardware devices from different vendors may have similar or compatible configurations. Each hardware device maintains configuration information in a proprietary format that requires vendor-specific administration software to access and/or modify. The vendor-specific administrator software migrates the configuration information between similar hardware devices (e.g., arrays or switches from a same vendor) but cannot migrate the configuration information between dissimilar hardware devices (e.g., arrays or switches from different vendors).
In other words, various parameters (e.g., a number of disks (e.g., virtual disks, hard disks), a number of storage volumes (e.g., LUNs), LUN sizes and layout, addresses of target ports (e.g., SCSI port), file system types (e.g., Windows NT File System (NTFS)), volume group ids and/or the like) associated with a source array cannot be automatically used to configure a target array from a different vender. Unfortunately, the various parameters have to be manually monitored, recorded and used to replicate/recover/rollback a configuration of the source array. Hence, restoring the configuration of the source array on the target array is a tedious and error-prone task.
Therefore, there is a need in the art for a method and apparatus for automating device recovery using device configuration information.